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continuation of U.S. patent application Ser. No. 08/396,1 98, 10 
filed Feb. 24, 1995, now U.S. Pat. No. 5,854,898 issued Dec. 
29, 1998. 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 15 
The present invention relates to teleconferencing systems. 
More specifically, the present invention relates to the 

addition of a data stream, such as an auxiliary data stream to 
a teleconference. 

2. Background Information A ° 
Teleconferencing is increasingly becoming a popular 

application in personal computer systems. Such applications 
typically allow the transfer of audio and video data between 
users so that they can speak and otherwise communicate ^ 
with one another. Such applications sometimes also include 
data sharing wherein various types of data such as 
documents, spreadsheets, graphic data, or other types of 
data, can be shared and manipulated by all participants in the 
teleconference. Different teleconference applications per- M) 
haps residing on different hardware platforms have different 
capabilities. Moreover, a wide variety of features has been 
implemented in different teleconference applications, and 
the proliferation of different types of computer systems with 
different capacities, and different networking media has 35 
created challenges for teleconferencing. 

For example, for most teleconferencing applications, it is 
assumed that the sender and the receiver have certain 
minimum capabilities. However, with the wide diversity of 
systems having different computation capacities, and in 40 
addition, the wide variety of networking media, that certain 
systems may not have certain capabilities. For example, the 
first system may be a high performance workstation coupled 
to a high performance communication medium whereas a 
second system may employ an earlier generation processor, 45 
operate at a substantially slower clock rate, and/or be 
coupled to a lower capacity communication medium. Cer- 
tain network capabilities such as multicast or other optimi- 
zation features, may not be present in certain networking 
media. Thus, in order for some teleconference applications 50 
to function, the participants in the conference can only 
operate at the fastest possible configuration provided by any 
minimum system which may participate in the teleconfer- 
ence. Of course, this results in certain inefficiencies, espe- 
cially if both of the participants are capable of transmitting 55 
in a higher capacity than the system with the least possible 
capability. 

Another issue in teleconference applications is the ability 
of certain stations to participate in more than one telecon- 
ference. !n fact, in certain circumstances, multiple individual 60 
conferences may be desired to be merged by a user accord- 
ing to operating circumstances. Due to the distributed nature 
of certain networks, during this merge operation, certain 
circumstances may change. That is, that while a single 
station is merging more than one conference it is participat- 65 
ing in, a second station at a remote location may further have 
other operating circumstances changing (e.g., participants 



leaving, entering, or otherwise joining an on-going 
teleconference), and thus, the management of such merging 
operations becomes unduly burdensome. 

Yet another shortcoming of certain prior art teleconfer- 
ence applications is the ability to associate an independent 
data stream with an on -going teleconference. For example, 
a source participant may desire to provide an additional data 
stream to other participants in a teleconference. This addi- 
tional source may include, but not be limited to, video, data, 
audio or any other type of data available to the source 
participant. For example, such an additional source may 
include other audio information for a receiver. Other types 
of data may also be desired to be associated with an 
on-going teleconference, which may be accessible to other 
participant in the teleconference. Certain prior art telecon- 
ferencing applications lack these abilitics. 

SUMMARY 

A method and apparatus for optimizing transmission of 
data to a plurality of second endpoints in a system wherein 
a first endpoint is providing data to the plurality of second 
endpoints each connected by point-to-point communication 
channels. This may be useful in teleconferencing applica- 
tions with a plurality of participants (endpoints) or broadcast 
server applications. The first endpoint activates a multicast 
communication channel having a first multicast address and 
commences broadcast of the data over the multicast com- 
munication channel. The first endpoint transmits a request 
message to each of the plurality of second endpoints in order 
to query each of the second endpoints whether they can 
receive transmissions broadcast to the first multicast 
address. Certain of the plurality of second endpoints trans- 
mit an acknowledgement message if they can receive trans- 
missions broadcast to the first multicast address, and the first 
endpoint receives the acknowledgement message. Then, for 
each acknowledgement message received from certain of the 
plurality of second endpoints, the first endpoint deactivates 
the point-to-point communication channel and the certain of 
the plurality of second endpoints. 

The broadcast of the data and the multicast communica- 
tion channel is terminated if at least two of the plurality of 
second endpoints do not transmit the acknowledgement 
messages containing a positive acknowledgement- In this 
instance, communication channels are maintained as point- 
to-point. Subsequent to commencing broadcast of the data to 
the multicast address, the first endpoint can receive detach 
messages from certain of the plurality of second endpoints, 
and if at least two of the plurality of second endpoints are not 
receiving the data, then the first endpoint can terminate the 
broadcast of the data and the multicast communication 
channel. Communication of the data in this instance also 
reverts to point-to-point communication channels. 

In implemented embodiments, the acknowledgement 
message includes a response code which indicates whether 
the second endpoint can receive transmissions broadcast to 
the first multicast address. Also, in implemented 
embodiments, prior to the first endpoint activating the mul- 
ticast communication channel having the first multicast 
address, it is determined whether the single communication 
medium supports broadcasting to the first multicast address, 
and if not, multicast cannot be activated. 

BRIEF DESCRIPTION OF THE DRAWINGS 
The present invention is illustrated by way of example 
and not limitation in the figures of the accompanying in 
which like references indicate similar elements and in 
which: 
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FIG- 1 illustrates an example configuration in which as limiting the present invention. Various mod ifica lions and 

various embodiments of the present invention may be iraple- other may be made by one skilled in the art, without 

moated. departing from the overall spirit and scope of the present 

FIG. 2 shows a typical teleconferencing display which has invention, 

both media and non-media sources displayed during the 5 a portion of the disclosure of this patent document 

course of the teleconference. contains material which is subject to copyright protection. 

FIG. 3 shows a single system in which embodiments of ^ copyright owner has no objection to the facsimile 

the present invention may be implemented. reproduction by anyone of the patent disclosure, as it 

FIG 4 shows an example architecture of a svstem appears in the Patent and Trademark Office patent files or 

employing various embodiments of the present invention i0 rccord& > tat otherwise reserves all copyright rights whatso- 

FIG. 5 shows a more detailed view of the conference eVCr C ° Pyright Apple ConipUter * InC " 

component illustrated in FIG. 4. A typical system configuration in which a teleconference 

cip c cK/ „ llc 0 M "r ♦ * f . may take place is illustrated as 100 in FIG. 1. For example, 

MO. 6 shows a sequence of typical conference events in a . f * «co • . «. 

a ™„fi.«»«~ o „ . - . * - . , . a first workstation 1:>0 may communicate via teleconference 

a conrerence component which are issued to an application. 35 . , , 4 . ... , _ 

r vv with a second workstation 155, as illustrated. System 150 

FIG. 7 shows a typ,cal sequence of steps performed for may iDchlde a ^ Dlnil processing unit 150c which is coupled 

member initialization within the conference component. t0 a display 15Qd a mput device 150flj and a 

FIGS. £-10 show typicaJ exchanges of messages for input device 1506. The system 150 may communicate with 

different operations. ^ over system 155 over networking medium 170 via network 

FIG. 11 shows a detail of a first endpoint establishing a *° connection module 160. 160 may include any number of 

teleconference. network adapters commercially available such as using 

FIG. 12 shows a sequence of steps performed in a second Ethernet, Token Ring, or any other networking standard 

endpoint receiving the messages sent from a first endpoint commercially available. Note that network adapter 160 may 

during the establishment of a teleconference. ~ also include * wireless network adapter which allows trans- 

ct/^c 1 1 A? l j. 1 r«i_ . * mission of data between components without a medium 170. 

5 - FIGS. 13-25 show details of the messages transmitted ~ ♦ • . . * _ . . . . 

r= . M A . t , . . . r - t . Communication is thus provided via network adapter 165 

— between endpomts during various teleconferencing apphca- , A > , 1K F , , . , " 

p u - ons coupled to system 155, and bi-directional communications 

f=s „ . may be established between two systems. System 150 fur- 

« HGS. 26a, 26b, 26c, and 26d show the steps taken for ^ Das a keyboard 150e and a pointing device 150/, such 

fy performing merge operations. 30 as a mQm ^ b ^ Qr Qther device for allowing ^ 

p FIGS. 27a and 27£> show the conferences before and after selections and user input. 

^ a merge operation between teleconferences. A le Ieconference display is shown at 200 at FIG. 2. In 

FIGS. 28a-b show a sequence of steps performed by the implemented embodiments of the present invention, there is 

; _ conference component during a merge operation. , 5 a source window, such as 201, showing a monitor of the 

^ i FIG, 29 shows an example of a merged conferences table l° ca l media source, and there are other media windows, such 

= within a single participant. as 202 or 203 for each other user with which a participant is 

La FIGS. Wa-30b shows a sequence of steps performed for havin S communication. In the illustrated example, each of 

U 1 converting point to point connections to multicast connec- the windows 201-203 provides media information, that is, 

= ^ tions for a teleconference 40 real-time audio and/or video information for bi-directional 

FIGS. 31 and 32 show the adding of an auxiliary source telccoQfercDcin 8- *■ ****** embodiments of the present 

m and the messages during the adding of the source to an * V< 7 h SJF * "f^T ^ ™ y J?** £ 

~ existing teleconference. ^ycd m ^ aa .t^ teleconferencing display. As will 

w rnno m *a w j m * * become apparent m the description below, in addition to 

u FIGS. 33-34 show the details of a sequence of steps media and Qon -media information, messaging information 

performed within a participant for adding an auxiliary may a lso be transmitted between stations. In addition, an 

source - auxiliary media source (e.g. audio or video information) 

FIGS. 35a-356 show an example sequence of messages may be transmitted with a specified conference. The details 

which are sent between a first endpoint and a plurality of of this will be discussed in more detail below, 

other endpoints in a networking system, and showing vari- ^ ln unpicmented embodiments of the present invention, a 

ous messages transmuted therebetween. general purpose compilter system is used for implementing 

DETAILED DESCRIPTION the tebcooferencing applications and associated processes 

10 be desenbed here. Although certain of the concepts to be 

The present invention relates to networking systems, described here will be discussed with reference to 

more specifically, -the present invention describes a messag- 55 teleconferencing, it is apparent that the methods and asso- 

ing protocol for establishing and maintaining teleconference ciatcd apparatus can be implemented for other applications, 

connections between a plurality of participants in a network- sucn as fi ' e sharing, real time data acquisition, or other types 

ing system. Applications for this include, transmitting appli- or applications which sends data from a first participant to a 

cation and/or system capabilities between participants or second participant or set of participants. A computer system 

potential participants in a teleconference, notifying partici- 60 SUCD 1021 used for implementing embodiments of the 

pants of a teleconference that more than one teleconference present invention will now be described, 

should be merged, and addition of an auxiliary data stream A computer system, such as a workstation, personal 

to an on-going teleconference. Although the present inven- computer or other processing apparatus 150c or 155c as 

don will be described with reference to certain specific shown in FIG. 1 is illustrated in more detail in FIG. 3. 150c 

embodiments thereof, especially, with relation to certain 65 comprises a bus or other communication means 301 for 

hardware configurations, data structures, packets, method communicating information, and a processing means 302 

steps, and other specific details, these should not be viewed coupled with bus 301 for processing information. System 
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150c further comprises a random access memory (RAM) or level, for example, ai the highest level in ibe ISO/OSI 
other volatile storage device 304 (referred to as main networking model, an application program 401, such as a 
memory), coupled to bus 301 for storing information and teleconferencing application, an audio/video server, or a 
instructions to be executed by processor 302. Main memory server, communicates with conference component pro- 
304 also may be used for storing temporary variables or 5 cess 400 in the form of Application Program Interface (API) 
other intermediate information during execution of instruc- ca *k conference component 400 allows the application 
tions by processor 302. Included in memory 304 during to establish communications between two or more telecon- 
run-time may be the conference component module which ffrence stations. Control information, and media inforrna- 
operates according to the communication protocols to be * on 030 l ™ n $mitted between the first participant system 
described below. System 150c also comprises a read only 10 and a 56001,(1 Participant system. The conference component 
memory (ROM) and/or other static storage device 306 m]] be j*?™ 11 m more detail in nG ' 5 ' Conference corn- 
coupled to bus301 for storing static information and instruc- |™ e * 400 communicates with the transport component 402 
tions for processor 302, and a data storage device 307 such b / scndin S Mov ie Talk messages for other teleconferencing 

as a magnetic disk or optical disk and its Corresponding disk TT* " enca ^ ale f aod P lat * d ,nt0 a fo ™ 

H - w rf ata ctrknm > . ; . ■ _ . . , V 7 the transport component 402, the network component 403, 

dnve. Data storage device 307 is coupled to bus 301 for 15 and lhe system network componenl 404 ^ P cketize and ' 

storing information and instructions. ^mit over networking medium 170. For the purposes of 
System 150c may further be coupled to a display device the remainder of this disclosure, certain of the MovieTalk 
adapter display 321 such as a cathode ray tube (CRT) or API calls and MovieTalk messages which arc transmitted 
liquid crystal display (LCD) coupled to bus 301 for display- between conference components in a teleconferencing sys- 
ing information to a computer user. Such a display 321 may 20 tem w iM be described in more detail, 
further be coupled to bus 301 for the receipt of video or The transport component 402 and the networking corn- 
image information. An alphanumeric input device 322, ponent 403 provide the necessary operations for communi- 
including alphanumeric and other keys may also be coupled cation over the particular type of network adapter 160 and 
to bus 301 for communicating information and command networking medium 170 according to implementation. For 
selections to processor 302. An additional user input device 25 example, networking component 402 may provide the TCP 
is cursor control 323, such as a mouse, a trackball, stylus, or or P rotc °k and packetizing, according to those 
cursor direction keys, coupled to bus 301 for communicating respective standards. 

direction information and command selections to processor A more delailc d view of the conference component 400 is 

302, and for controlling cursor movement on display 321. shown in FIG. 5. Specifically, the conference component 

For teleconferencing applications, system 150c may also 30 ^ k sbown m two portions 400a and 4006 which show 

have coupled to it a sound output device 324, a video input ^P 111 ^ output portions of the conference component, 

device 325, and sound input device 326, along with the Although illustrated as a separate transmitter and receiver, 

associated D/A (Digjtal-to-Analog) and A/D (Analog-to- each conference component in the system has both 

Digital) converters for inputting or outputting media signal capabilities, so that full bi-directional communication 

bitstreams. System 150c may further be coupled to commu- 35 oetwccn conference components in respective participant 

nication device 327 which is coupled to network adapter 160 teleconference systems in a network may communicate with 

for communicating with other teleconferencing stations. one mother. As illustrated, the input portion of the confer- 

Note, also, that anv or all of the components of system ence com P onenl 400(2 receives video and sound information 

150c and associated' hardware may be used in various over media mput channels 510 and 520. The video channel 

embodiments, however, it can be appreciated that any con- 40 com P OQenl and sowd channel component 504 present 

figuration of the system may be used for various purposes mectia dala at regular mtervds t0 grabber 502. The 

according to the particular implementation " * real-time sound and video data (hereinafter referred to as 

In one embodiment, system 150c is one of the Apple ^ m *Z ^T* Strean ^ direclor 500 

Computer® brand family of personal computers suchafL fr ° m 502 wmch med,a 

Macintosh 8100 brand personal computer manufactured by 45 TT* *** !^ a ^P^ component 402. Flow Control 501 

Apple Computer, Inc. of Cupertino Calif. Processor 302 tels ^ ^ "* ^ Bl a ° 

may be one of the PowerPC brand microprocessors manu- Z™^ 1 * ? ^ ^ * anoc J 

factured by Motorola, Inc. of Schaumburg, 111. component 503, sound channe component 504, and 

,k,. ,u f n r • , sequence grabber 502 all are implemented using prior art 

niSfrr™ j followmg discussion of various embodi- 50 producls such „ ^ ^^^y available (e.g., the 

ments discussed herein will reter .pecificaUy to a series of QuickT imc video channel, sound channel component and 

S arC S CTcra i cd in a high-level programming seque nce grabbers, avaflable from Apple Computer, Inc. of 

SZnS n*Li ul T P^™"* language) and Cupcrtul0> CaJit) Row ^1 501 may be implemented 

compfled, linked, and then run as object code m system 150c usiDg ^ flow co nlro i apparatus and/or mel hod as are 

SaTnl^h ™™Z 3W ^ LTT n 2 55 commerciaUy avaflable, such aTmose which regulate flow 

r^'t P k, i t ge TA ted *"J?£ based U P°° bandwidth, and other constraints in the source 

Compiler available from Symantec, Inc. of Cupertino, Calif. participant system. The conference component further com- 

Although a general purpose computer system has been prises a sink stream director 510 which comprises a portion 

described, it can be appreciated by one skilled in the art, of the component 400* of the conference component for 

however, that the following methods and apparatus may be 60 receipt of media data from transport component 402. Cor- 

lmplemented in special purpose hardware devices, such as responding flow control 511, video and sound stream pla vers 

discrete logic devices, large scale integrated circuits (LSI's), 512 and 513, and compression and sound manager 514 and 

application-specific integrated circuits (ASIC's), or other 515, for output of video streams 530 and 540, also form part 

specialized hardware. The description here has equal appli- of the conference component for fiill bi-directional confer- 

cation to apparatus havmg similar function. 65 encing capabilities. 

FIG. 4 illustrates a plurality of processes and/or apparatus The conference component's main function is to establish 

which may be operative within system 150c. At the highest and maintain a bi-directional connection between everv 
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member of a conference. Conferencing applications use a A typical application's initialization is shown as process 

pre-established control channel to exchange control data that 700 of FIG. 7. The application program makes a number of 

is pertinent to the conference. This data might include user API calls in order to set various parameters associated with 

identification informaUon or other information thai is ger- the member or potential participant. First, an application 

mane to the app^cation s operation. Conferencing applica- 5 may cause the conference component to set its capability at 

tons e.g., 401) define fl» format and content of these st 702 tf h k differeQt ^ ^ defauJ ^ J 

™Tl£Tr ^ CStabllshlD S t , own P"*>" "MTConferenceSetMessageCapabiKties" causes the confer^ 
cols. The conferencing component further establishes com- „„, _ . „ * \ T~ , 

munication channels between a first endpoint and a second ^ ?v ^ ^ * a PP l,caU ™ 

endpoint, using the underlying transport component 402. ca Pf^^ies within the conference component for the specific 

Thus, once a media channel has been established, the 10 wtudl ^ter used during transmission of 

conference component uses the transport component 402's messages to alert rec ip ients that the sender application has 

media channel which is provided for transmission of media certajn functlona * capabilities prior to the establishment of a 

and non-media information. For the remainder of this connection between the sender and the receiver. Each capa- 

application, however, the focus will be on the establishment bili,v nas associated with it a type, version, and "desire" of 

of communication between a first and second participant 35 tne capability. Each desire for each capability type may be 

(referred to as endpoints) or group of participants which may flagged as: 

participate in a teleconference. 1. optional; 

Application Program Interface (API) 2 - desired; 

Tne application program 401 controls the conference 20 3 " required; or 

component 400 by the issuance of MovieTalk application 4 - a negotiation message. 

API calls. The conference component operates using an These types of capabilities are included in a capabilities list 

event-driven model wherein events pertinent to the applica- which is transmitted to endpoints, as will be described 

tion are issued to the application program. The application below. An "optional" capability is a message which is not 

program can then take appropriate action either by modify- 25 rea . u ired 10 ^ exchanged before setting up a conference. A 

ing internal data structures within (creating a source or sink), "desired" capability is one which is not required that it be 

and/or issuance of appropriate messages over the network to exchanged before setting up a conference, however, it is 

other connected participants, or potential participants. preferred that it is. A "required" capability is one which 

According to messages received by the conference requires that a message be exchanged before setting up a 

component, a current context and API calls from the 30 conference. This may include access control or other tnes- 

application, the conference component can take appropriate sages which are transferred prior to setting up a conference, 

action. An access control capability may include the transmission of 

A typical series of events which occur after the establish- a account number and password prior to the commencement 

ment of a teleconference by the conference component in an of a teleconference. A "negotiation message'* is a capability 

application is illustrated in FIG. 6 as 600. For example, upon 35 which indicates that the application wishes to query the 

an initial desire by an application to enter into a conference receiving application. In the case of a negotiation message 

(as expressed by an API call) or a call from another capability, the type field associated with the capability 

participant, a conference-ready event 601 (e.g. allows the requests of information about the applications 

mtConferenceReadyEvent) is generated. The application pnor 10 lhe establishment of a conference (e.g. aboul the 

then creates a media source in the conference component 40 i y^ t °fso ftwa re and hardware components the application is 

(eg., member A) which is to provide the conference infor- interested in, such as sound). Any other types of exchanges 

mation. Subsequent to that, any auxiliary media sources may w mch require negotiated information between applications 

also be attached to the main conference at step 610 for a ma y be scL 

second media source (e.g. by the call MTConferenceAi- ° nce aI1 ^dividual capabilities have been set by the 
tachAuxfliary Source). Then, any members that are new to 45 issuancc of " Sc t Capabilities'* API calls (e.g. 
the conference are recognized as being ready by the receipt MTConferenceSetCapabilities) to the conference com po- 
of MemberReady (e.g. mlMemberReady) events (e.g., 602 nem at slc P 702 > a member may set its operating mode at 
and 603 of FIG. 6). This establishes the media sinks such as sle P 704 ^ mode wiU contained within a mode mask 
b and c illustrated in FIG. 6. Then, during the teleconference vaIuc whicn is xal in me AP J 10 ^ conference 
session, a variety of other events 604 may be issued and 50 component, and moreover, is included in certain messages 
acted upon by the conference component These may transmitted from the conference component in the sender to 
include message events, mode events, incoming call events, **** conference component in the receiver. The mode mask 
data transmission events, etc. Members leaving the confer- specifies the characteristics of a conference that the member 
ence result in the issuance of MemberTerminated (e.g. makes available. Different capabilities, modes, and other 
mtMemberTerminatcdEvent) events to the application pro- 55 initialization operations shown in FIG. 7 may be set for any 
gram such as 605 or 606. Thus, for every MemberReady number of conference types which arc made available by the 
event for any member participating in a conference, there is member. At any rate, the default mode includes the follow- 
a corresponding MemberTerminated' (e.g. ing values: 
mtMemberTerminatedEvent) event prior to the end of the mt( *™'> 
conference. In addition, the auxiliary source and the con- 60 2. receive media; 
ference itself is terminated via the Auxiliary Terminated (e.g. 3. shareable; and 
mtAujriliaryTenninatedEveni) eve ni 611 and the conference 4. joiner. 

terminated event 607 as illustrated in 600 of FIG. 6. This The "send media" mode flag indicates that the member 

notifies the application that the conference is terminated, and intends to send media data in its conferences. Most members 

teleconference data should no longer be transmitted. Any 65 will want to send media, however, there will be instances 

additional clean up operations are then performed by the where the member will be a receive-only member, thus lhe 

application, and the source may be discarded. send media mode flag will not be set Hie receive media 
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mode flag indicates that the member intends to receive cation to specify whether the registration attempt was suc- 

media in conferences. In the case of a send-only member cessful. After listeners are operational, if another application 

(e.g., a server providing a real- lime video and/or audio desires to establish communication with the application, 

source), will have the receive media mode flag set to "off" then an mUncomingCallEvent is forwarded to the applica- 

(e.g., a numeric value '0'). The "shareable" mode flag 5 lion. 

indicates that the member is willing to share the conference FIGS. 8-10 show examples of the various message 

media data with new conference members. Thus, in the exchanges between two endpoints. Messages are generated 

instance of a send-only media server, the shareable mode by conference component 400 depending upon operating 

flag would be set indicating that new members can receive context, and application calls. FIG. 8 shows an example of 

the conference data. io a calling sequence for setting up a conference between two 

r lne "joiner** mode flag indicates that all conference endpoints. Upon the commencement of a call from a first 

members are allowed to interact. This would allow two-way endpoint such as 810 shown in FIG. 8, and a second 

transmission between each of the conference members. endpoint such as 820 shown in FIG. 8, a "capabilities" 

However, the setting of this flag to "off" (e.g., a numeric message 802 is transmitted from the endpoint 810 to the 

valued) results in broadcast type conferences wherein one is endpoint 820 if they have been set by the caller. The 

member sends media data to other conference members, but exchange of "capabilities" messages 802' and 812 between 

the individual conference members do not exchange any endpoint 1 810 and endpoint 2 820 are exchanged after a 

media data among themselves. Each of these mode flags is control channel has been opened on the transmission 

transmuted at the beginning of a connection (e.g., contained medium between the participants in an implementation- 

within the "hello" message 1400 in FIG. 14). 20 dependent manner (e.g. by invoking MTConferenceCall). 

By default, the conference component establishes confer- This identifies the capabilities of each of the endpoints, if the 

enccs that are fully two-way media data capable, shareable, capabilities of the application are desired to be transmitted, 

and joinable. If different characteristics are desired, then the Once capabilities have been transmitted from each endpoint, 

application must call "set mode" (e.g. each endpoint further transmits Hello messages 804 and 814 

MTConferenceSetMode) at step 704, along with the appro- 25 to identify themselves. The details of the capabilities, Hello, 

5^ priate flag(s) set. Conference mode settings arc stored and and other messages illustrated in the figure will be discussed 

associated with a particular conference ID in the sender's below. The Hello message is the first step in establishing a 

y conference component so that when messages are created conference, and allows conference components in different 

O for that conference ID, the appropriate mode flags are systems to exchange basic identification and mode informa- 

fy transmitted along with the initialization or other messages 30 tion. Subsequent to the exchange of Capabilities messages 

p~ t** 1 tefore any other communications. (if any), and the Hello messages 804 and 814, the endpoint 

In addition to the capabilities and mode settings at steps 1 810 wishing to establish the conference sends a call 

U \ 702 311(3 704, a time-out value associated with calls placed message 806 to endpoint 2 820. Subsequent thereto, if 

y from the member may be set (e.g. using the API call endpoint 820 desires to engage in the teleconference with 

\^ MTCorofereirceSetTtaeOut). The timeout value is then 35 endpoint 1 810, it sends a response message 816 to endpoint 

- 1 mcluded at the beginning of certain messages preceding a 1 810. Then, upon the transmission of the call message 806 

s conference in order to enable a recipient to determine when and the receipt of the response message 816, a teleconfer- 

the caller will stop listening for responses. This allows ence is then established between endpoint 1 810 and end- 

certain features to be incorporated into participant confer- point 2 820. The details of the process steps performed 

! T' cnce components such as the smart triggering of events 40 within each endpoint are discussed with reference to FIGS 

f=s based upon context. For example, if the recipient is receiv- 11 and 12. 

rr) ing a call, but a user does not wish to take the call at that FIG. 9 illustrates a "Join" protocol process. This is similar 
i= time, the recipient's conference knows the time-out occurs to the calling process, however, a "Join" message 906 is sent 
]*7 and can take certain context-dependent action (e.g., forward to the second endpoint instead of the "call" message 806. 
M= the call, send a message, etc.). 45 The details of a Join are discussed with reference to FIGS. 
The application can then invoke an API call "Listen for 26<i-26c below. 
Call" (e.g. MTConferenceListen) which implements steps FIG. 10 illustrates the messages exchanged for a termi- 
708 and 710. At step 708, using the underlying transport to nate message. As illustrated, an endpoint may issue a 
which the system is connected, a high level address is terminate message to terminate a teleconference. No 
registered and published. This then allows other potential 50 response is required for any receivers, 
participants in the system to call the member. The registra- FIG. 11 shows the process steps performed by a first 
tion and publication of the address is implementation- participant (e.g., endpoint 1 810) wishing to establish corn- 
dependent, depending upon the media to which the system munication with a second participant system (e.g., endpoint 
is connected. Then, at step 710, the conference component 2 820). First, at step 1102, the caller via implementation- 
waits for incoming calls. 55 dependent means, accesses the address of the party it wishes 
The conference component in the member enters an idle to call, either by reference to an internal store, referencing a 
state wherein incoming messages, alerts for the transport server or other implementation-dependent manner. Once this 
component, API and calls will be detected and acted upon. has been performed, the application invokes the API call 
Note that the capabilities, mode, and time-out values are all MTConferenceCall in order to call the party at step 1104. 
optional, and the default settings may be used by the 60 Responsive thereto, either a failed event 1106 
member if none of these functions is required by the (mtFailedEvent) is received by the caller, or a ringing event 
application. In the call to the MTConferenceListen function, 1108 (mtPhoneRingmgEvcnt) when the call message has 
the application must specify the networks on which the been transmitted to the second participant. In the event of a 
member is willing to accept calls. The conference compo- ringing event, the endpoint can then get the capabilities, 
nent proceeds to register the member on those networks, 65 mode and the name ot thee ndpointsuch as by examining the* 
doing whatever is appropriate in the various network data contained in the Capabilities message 812 and/or the 
contexts, and sends an mtlostenerStatusEvent to the appli- Hello message 814. Any "required" communication between 



4 



5,999,977 

11 12 

the caller and receiver may also be performed. Then, the first 1300 or an Auxiliary message 1700. The member then sends 

sender can appropriately configure itself for the second a Hello message 1400 to identify itself, specifically its mode 

endpoint. Once any necessary message exchanges and/or of operation (send media, receive media, shareable, or 

configurations have been performed in the caller, then the joiner) followed by a Call message 1500 (to set up a 

caller will either receive a MemberRefused event 1112 (e.g. 5 conference) or a Join message 1800 (to join to an ongoing 

mtRefusedEvent), for example, if the calling member does conference). The remote member sends a Response message 

not provide the necessary access control subsequent to the ^ answer to the Call or a Join message 1800. Once a 

call message, or, a MembcrReady event 1116. Also, a failed conference is established, a member can combine calls or 

event 1106 can be detected at any time, followed by a conferences by sending a Merge message 1900. Conference 
MemberTerminated event 1114. In the case of a Member- 10 members may send or receive a Terminate message 2300 to 

Refused event 1112, then the conference component will cnd a conference. Connections initially arc point-to-point 

generate a MemberTerminated event 1114, and a conference between members of a conference. If the transport medium 

terminated event will then be issued indicating the end of the supports multicast addresses and more than one member is 

conference. Once capabilities have been obtained, any participating in a conference, a broadcast to a multicast 
required capabilities are checked for at step 1113 (e.g. such 15 address can be used as an optimization. The conference 

as any actions that must be performed before the receiver component uses the BroadcastRequest and BroadcastAck 

accepts the call). Subsequent thereto, a Confer- messages 2400 and 2500 to negotiate the transition from 

enceReadyEventlll5 (e.g. MTConfReady Event) and a point-to-point to multipoint connections using multicast 

MembcrReady event 1116 (e.g. mtMcraberReadyEvent) can addresses. 

be received by the application, then the endpoint can then 20 AM messages supported in the conference messaging 

engage in the exchange of messages typical during a protocol are preceded by a 2-byte character identifying the 

conference, thus commencing the conference at step 1118. message type. For example for a capabilities message shown 

As shown in FIG. 12, the sequence of steps performed by m FIG. 13, field 1302 contains a 'K\ All messages are 

the receiver is illustrated. For example, at step 1202, the further terminated by a NULL such as that shown in field 
receiver application will detect an incoming call event 1202. 25 1308 of FIG. 13. The Capabilities message 1300 allows a 

Subsequent thereto, the receiver can then determine mode, potential member to tell other potential conference members 

capabilities, caller's name, conference name, and/or return wnat can aQ d cannot do in a conference. Each member 

address of the party wishing to engage in the conference. sends this message before sending the "Hello 7 ' message 

The mode can also be checked for at step 1206. Once this (1400 of FIG. 14) if capabilities other than the default are 

has been done, then a time-out check, if any, at 1208 can be 30 supported, 
performed in the receiver. The time-out check may be 
performed, depending upon an application's 
implementation, by checking the time-out field shown at 
field 1504 in FIG. 15, which indicates how long the trans- 
mitter will wait prior to timing out and generating a Call- 35 
Failed event (e.g. mtFailedEvent) in order to terminate the 
call. In this case, according to implementation, the receiver 
may do a variety of things, for example, issuing a busy 

signal to the transmitter, issuing a message to the caller or, capabilitiesList 1306 

taking some action, such as forwarding the call to another 40 The member 's capabilities. This field is optional. If 

party. Thus, the embedding of the time-out field 1504, within specified, it contains a list of the member's capablili- 

the initial connection message "Hello," provides for certain ties. An application specifies its capabilities by calling 

intelligent features in the potential participants of a telecon- the conference component's MTConferenceSetMes- 

ference. Once any mode checks, if any, have been performed sageCapabilities function. 

at step 1206, then at step 1208 a lime out check, if any, may 45 The Capabilities message 1300 shown in FIG. 13 informs 

be performed. Any user interaction may take place at step other potential conference participants about a member's 

1209. The receiver will then issue a reply at step 1210. The capabilities. These capabilities relate directly to messages 

reply may indicate either refusal to answer the call (e.g., due the member either supports or requires, one capability for 

to access control, or the participant already engaging in each conferencing message type that the component sup- 

another conference), or choose to respond to the call in the 50 ports. The messages themselves are defined by the type of 

affirmative indicating that the teleconference may com- applicauon the member is running. Tor example, video- 

mence. In the case of a refusal, the MemberTerminated 1220 phone applications and chat lines deliver different services, 

event (mtMemberTenninatedEvent) is issued to the appli- and use different messages to do so. As a result, the 

cation. In the case of the member answering, the Member- capabiliues a member supports will change in light of the 

Ready event 1218 (mtMemberReady Event) is issued indi- 55 application that is participating in the conference. Entries in 

eating that the medium channel is open and the conference the capabilitiesList field may request information from the 

can commence. remote system. By setting an entry's "desires" field (2010 of 

Conferencing Messages HG - 20 > m^egotiationMessageapabilities ('N'), a confer- 
ence member can query for specific information (e.g. about 

Conference components exchange a number of messages 50 a given component type, such as a codec, hardware/software 

in order to establish, maintain, and terminate conferences. features supported, etc.). The type field can contain the 

Conference components also send messages that encapsu- component type value. 

late user data, that is, the data that is exchanged by the i n response to a negotiation Capabilities message, the 

programs that are using the conference. remote member formats a user data message, for example, 

After establishing a transport connection but prior to 65 containing available component subtypes. Note that this list 

establishing a conference channel with a remote system, a may contain duplicate entries and entries with a value of 

conference member may send either a Capabilities message NULL. To parse this array, a member must determine the 



Field 


Size 


Value 




type 1302 


2 bytes 


'K* 




delimiter 1304 


1 byte 


newline 




capabilitiesList 1306 


O-n bytes 


(alphaoumt 


rric) 


terminator 1308 


1 byte 


NULL 
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array's size. After sending a Capabilities message 1300, the 
member sends a Hello message 1400 to establish a confer- 
ence. 

A Hello message (e.g., 1400 of FIG. 14) is sent at the start 
of a conference by each endpoint. The Hello message 
identifies basic capabilities of the sender and the mode in 
which it will operate. It contains the following: 











-continued 




Field 


Size 


Value 


delimiter J 506 


1 byte 


tab 


ConferenceName 1508 


1-n bytes 


(alphanumeric) 


delmiitei 1510 


1 b>tc 


newhne 


callingConflD 1512 


1-n bvtes 


(alphanumeric) 
newhne 


delimiter 1514 


1 byte 


teioiiaator 1510 


1 byte 


NULL 



Field 


Size 


Value 


type 1402 


2 bytes 


'H* 


Minimum Version 1404 


1-n bytes 


(numeric) 


delimiter 1406 


1 byte 


colon 


maximumVfcision 1408 


1-n bytes 


(numeric) 


delimiter 1410 


1 b>te 


new line 


conferenceMode 1412 


1-n bytes 


(numeric) 


delimiter 1414 


1 byte 


oewline 


name 1416 


1-n bytes 


(alphanumeric) 


delimiter 1418 


1 b>te 


newKne 


terminator 1420 


1 byte 


NULL 
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minimum Version 1404 

The oldest version of the conference protocol supported 
by the sending component 
maximum Version 1408 
The newest version of the conference protocol supported 
by the sending component. 
conferenceMode 1412 

The desired conference operating mode. This field con- 
tains a value that corresponds to the operating mode the 
sender desires for this conference. Applications specify 
their desired mode by a SetMode API call (e.g. 
MTConferenceSetMode discussed above), 
name 1416 

The name of the prospective conference member. This 
name identifies the entity that wants to join the 
conference, and may represent either an auxiliary data 
source or a new user. Applications specify a user name 
by calling the MTConferenceListen API call. The aux- 
iliary name is specified in a NITAltachAuxiliary API 
call. 

The Hello message 1400 is the first step in establishing a 
conference. This message allows conference components on 
different systems to exchange basic identification and capa- 
bility information. Before sending a Hello message 1400, a 
conference component may send either a Capabilities 1300 
or an Auxiliary message 1700. The type of message sent 
depends upon the role the member anticipates playing in the 
conference. If the member is looking to join or start a 
conference, the conference component sends a Capabilities 
message. If the member is setting up an auxiliary media data 
source, the component sends an Auxiliary message 1700. 
Following this message, the conference component can 
enter the call setup phase by sending the Call message 1500. 
If the member wants to provide an auxiliary data source to 
an existing conference, or join an existing conference, the 
component sends the Join message 1800. 

Call message 1500 of FIG. 15 begins the process of 
establishing a conference connection between two possible 
participants. This is akin to dialing a number from a phone 
directory. 
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25 
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callTimc-out 1504 

The amount of lime the calling component is willing to 
wait for an answer. This field specifies the number of 
licks (Vgo of a second) the calling component will wait 
before deciding thai the call has not been answered. 
Called components must respond within this time 
period. This value may be used by a potential responder 
for taking some automatic action if the user doesn't 
answer before the timeout. 
ConferenceNarae 1508 
The conference name. If the caller is establishing a 
conference, this is the name the caller has assigned to 
the conference. If the caller is connecting to a confer- 
ence server, the is the name of the server's conference. 
Applications sei I he conference name by calling the 
MTConferenccCall function. 
callingConflD 1512 
The caller's unique conference identifier. This field 
uniquely identifies the caller's conference endpoint on 
the network. Conference components create conference 
identifiers on behalf of calling applications which are 
unique within the conference component. Call ID's are 
discussed with reference to 2200 of FIG. 22. 
The Call message 1500 shown in FIG. 15 begins the 
35 process of establishing a conference between two partici- 
pants. This message can be used in two ways. First, this 
message can create a conference between two participants. 
In this scenario, the caller assigns a name to the conference, 
so that other possible participants may join later. 
40 Alternatively, this message can request to join a conference 
that is managed by a conference server on a network. For 
example, the server will allow incoming calls, but the 
function of the server is to merge the new conference due to 
the call with other ongoing conferences. In other words, the 
45 server acts exclusively as a "joiner" and does not supply 
media data. Once the call is set up, the caller can begin 
exchanging user data with other conference participants. 

The response message 1600 of FIG. 16 is sent in response 
to Call or Join messages 1500 or 1800. 

50 
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Field 


Size 


Value 


type 1602 


2 bytes 


4 R* 


call Response 1604 


1-n bytes 


(signednnmeric) 


delimiter 1606 


1 byte 


newiine 


destiaatioaCbnflD 1603 


1-n bytes 


(alphanumeric) 


delimiter 1610 


1 byte 


newiine 


terminator 1612 


1 byte 


NULL 



Field 



Vahic 



type 1502 
cairrime-out 1504 



2 bytes 
1-d bytes 



(numeric) 



50 callResponse 1604 

The result. This field indicates the result of the preceding 
Call request. This field is set to *0' if the request was 
successful. Otherwise, it contains an appropriate result 
code. 

65 destinationConflD 1608 

The other endpoint 's unique identifier. This field identifies 
the other participant in the conference. 
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The Response message 1600 allows the caller to determine 
the success of a Call or Join request. The Response message 
1600 indicates how the user at the remote system reacted to 
the call (for example, whether the user answered the call). 
The callResponse field 1604 contains the request's result 
code. If non-zero, an error occurred and the request was not 
successful. Otherwise, the destinarionConfID field 1608 
identifies the endpoint with which the caller may now 
communicate 

The auxiliary message 1700 allows one member to alert 
the other members of a conference that it is about to provide 
an auxiliary media data source (a source associated with an 
ongoing conference). This message may be used in place of 
the Capabilities message 1300 if a participant is being 
alerted about the presence of an auxiliary media source. The 
member sends this message before sending the Hello and 15 
Join Messages 1400 and 1800, and then proceeds to adding 
an auxiliary data source to the conference. 



J0 



Held 



Size 



Value 



20 



type 1702 
parcntConnn 1704 
delimiter 1706 
terminator ] 708 



2 bytes 
1-n byles 
1 byte 
1 byte 



(alphanumeric) 

ncwlioc 

NULL 



memberLisl 1812 
A list of other conference participants. This list identifies 
all other known conference participants that arc willing 
to exchange data with new participants (that is, they 
have the Joiner Mode Mask [e.g. m JoinerModeMask] 
set in their conference mode) The conference compo- 
nent can connect with each participant with whom it is 
not already connected. If the message is adding an 
auxiliary (via the issuance of an auxiliary message 
1700), this list contains the endpoint identifier of each 
participant to which the caller is making the auxiliary 
available. It is up to each of them to respond. 
This is a list of conference endpoint identifiers; each 
element in the list is followed by a newline character. 
The Join message 1800 allows a member to add an 
auxiliary data source to an existing conference or to merge 
two existing conferences. The caller sends this message to 
members of the conference in response to a merge or join 
request instead of a call message. 

The Merge message 1900 of FIG. 19 combines two 
conferences. Recipients of this message connect with the 
listed members with whom they are not already connected. 



parentConOD 1704 

The member's conference identifier. This field identifies 
the member's existing conference endpoint (the con- 
ference identifier the member supplied in the Call 
message when it first joined the conference). This 
allows other conference participants to identify the 
source of the auxiliary data within each participant. 
The Auxiliary message 1700 informs other conference 
participants that a member is about to provide an auxiliary 
conference data source. For auxiliary data sources, this 
message replace the Capabilities message during early inter- 
act ions. The member must send this message to each con- 
ference participant. The member then sends a Hello 1400 
and a Join message 1800 to each participant. Other partici- 
pants then accept the new data source by accommodating the 
Join request. 

A Join message 1800 of FIG. 18 allows a member to join 
an existing conference, given that conference's identifier. 
This message is useful for adding auxiliary data sources to 
an existing conference, and for merging two existing con- 
ferences. 



25 


field 


Size 


Value 




type 1902 


2 bytes 


•M' 




conferenceName 1904 


3-n bytes 


(alphanumeric) 




delimiter 1906 


1 byte 


newline 




myConftD 1908 


1-n bytes 


(alphanumeric) 


30 


delimiter 1910 


1 byte 


newline 




member List 3932 


0-n bytes 


(alphanumeric) 




terminator 1914 


2 byte 


NULL 



field 


Size 


Value 




type 1802 


2b>tes 


'J* 




deslinationConflD 1604 


1-n bvtcs 


(alphanumeric) 




delimiter 1806 


1 byte 


newline 




callingConOD 1808 


l-o bytes 


(alphanumeric) 




delimiter 1810 


1 byte 


newhnc 




memberLisl 1812 


0-n bytes 


(alphanumeric) 




terminator 1814 


1 byte 


NULL 
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destinationConf ID 1804 

The remote endpoint 's unique conference identifier. This 
field identifies the conference to join on. $0 

callingConOD 1808 

Unique conference identifier. This field uniquely identi- 
fies the caller's conference endpoint on the network. 
Conference components create conference identifiers 
on behalf of calling applications. If the message is 65 
adding an auxiliary media data source, this is the 
auxiliary's identifier. 



conferenceName 1904 
The new conference name resulting from the merge. This 
is the name that was assigned to the conference when 
the conference was established. Applications specify 
the conference name by calling the MTConferenceCall 
API function. 

myConfID 1908 

Unique conference identifier. This field uniquely identi- 
fies the caller's conference endpoint in the target con- 
ference. Conference components create conference 
identifiers on behalf of calling applications, 
memberlist 1912 
A list of other conference participants. This list identifies 
other current conference participants. This list contains 
the endpoint identifier of each new participant This is 
a list of conference endpoint identifiers; each element 
in the list is followed by a newline character. 
'ITie Merge message causes the combination of two con- 
ferences. This is the mechanism for creating conferences 
with more than two participants. The caller sends this 
message to each existing conference member, specifying the 
conference's name. Each endpoint establishes communica- 
tions with any new endpoinis. By convention, the endpoint 
with the higher conference identifier value establishes the 
connection (to avoid duplicate or missed connections). 
Members of the conference receive a Join message 1900 
instead of a Call message 1500 when contacted by each new 
member. 

Field Specifics 

A capabilities list such as shown in FIG. 20 (e g., field 
1306) contains information about the message supported by 
a conferencing application. The list consists of zero or more 
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lines of information; each line specifies a single capability 
and consists of the following fields.: 



Field 


Size 


Value 


type 2002 


4 bytes 


(alphanumeric) 


delimiter 2004 


1 byte 


tab 


versioo 2006 


1-d bytes 


(numeric) 


delimiter 2008 


1 byte 


tab 


desires 20 JO 


1 byte 


(alphanumeric) 


delimiter 2012 


1 bvte 


newline 



FieJd 


Size 


Value 


UniquelD 2202 


1-n bytes 


(numeric) 


separator 2204 


1 byte 


space 


name 22sJ 0 


1-n bytes 


(alphanumeric) 



UniquelD 2202 

Unique numeric identifier. This field contains a unique 
numeric end point identifier. Each conference compo- 
nent assigns its own identifiers in order to guarantee 
uniqueness within the context of a given name specified 
in the name field 2206. 

name 2206 

A unique name. Identifies the system on the network. The 
name is unique within the context of a given transport 
interface. It includes the type of the selected transport 
and oetwork interface. 
A member lisi such as 1812 of FIG. 21 is an array of zero 
or more conference identifiers 2102,2110, etc. Each entry in 
the array is delimited by a newline character. 
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message 2300 of FiG. 



The Terminate message 2300 of FiG. 23 ends a 
conference, closing a member's communications with the 
participants to which it sends the message. 
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Field 


Size 


Value 


type 2302 


2 bytes 


T 


delimiter 2304 


J byte 


newline 


terminator 2306 


1 byte 


NULL 



type 2002 

Identifies a message by reference to a unique type value, 
version 2006 

Message version number. Specifies the most-recent ver- 
sion of the message thai the application supports, 
desires 2010 

Support level. This field indicates the level of support 
required by the application. Possible values are: 
mtMessageOptionalCapability 

Optional Indicates that the message is optional. The 
value corresponding to this option is *0\ 
mtMessageDesiredCapability 
Desired. While still optional, this value indicates that 
the application prefers to receive this message 
early in the call (e.g. prior to establishing a call, 
one member may request that the recipient send 
his business card for long-term storage). The value 
corresponding to this option is l D\ 
mtMessageRequiredCapability 
Required. The application must receive this mes- 
sage. The value corresponding to this option is 

mtNegotiationMessage Capability 

Negotiate. The application wants to learn about the 
recipient's facilities. The value corresponding to 
this option is 'N'. 
Conference identifiers such as 2200 shown in FIG. 22 
uniquely identify a conference endpoint. Each endpoint 
represent a data source or sink for the conference. Note that 
a single system may have more than one conference end- 
point (e.g., an auxiliary) in a given conference, and may 
have more than one conference at a time. A conference 
endpoint consists of the following fields: 



The Terminate message 2300 is the last step in ending a 
member's participation in a conference. This message ends 
the member's conference communication with all partici- 
pants to which it sends the message. If a member is leaving 
a conference altogether, it must send this message to each 
conference participant. 

The BroadcastRequest message 2400 allows a member to 
find out if another conference member can accept broadcast 
(multicast) messages. 



Field 


Size 


\fclue 


type 2402 


2 bytes 


'B* 


subtype 2406 


lbyte 


'R* 


delimiter 2408 


1 bvte 


tab 


multicdStAddress 24] 0 


1-n bytes 


(alphanumeric) 


delimiter 2412 


1 byte 


newline 


terminator 2414 


lbyte 


NULL 
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subtype 2406 

The broadcast message subtype. This field must be set to 
'R\ 

multicastAddress 2410 
The proposed multicast address. This field contains the 
multicast address on which the member proposes to 
send broadcast messages. 
The BroadcastRequest message 2400 allows a member to 
determine whether another conference member can accept 
broadcast messages over a given multicast network address. 
40 The recipient indicates its ability to support the broadcast 
messages by sending a Broadcast Ack message 2500 
(described below). If the recipient cannot support broadcast 
messaging or cannot access this particular broadcast 
transmission, the calling member should continue to send 
45 point-to-point messages to the recipient. 

The BroadcastRequest message 2400 is typically uses as 
part of the negotiation process that follows merging two 
conferences or the joining of any new members to a con- 
ference. As an optimization, conference participants may 
choose to set up broadcast capabilities as a more-efficient 
alternative to maintaining several different point-to-point 
connections. 

The BroadcastAck message 2500 allows a member to 
respond to a BroadcastRequest message 2400. 



60 



50 



Reid 


Size 


\Wue 


type 2502 


2 bytes 


*B* 


subtype 2504 


1 byte 


'A' 


delimiter 2506 


lbyte 


tab 


broadcasiResponse 2508 


1-n bytes 


(signed numeric) 


delimiter 2510 


1 byte 


cewiine 


terminator 2512 


1 byte 


MULL 



65 subtype 2504 

The broadcast message subtype. This field must be set to 

'A'. 
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broadcaslResponse 2508 whether the member merging membership is shareable. If 

The result. This field indicates whether the member can so, then at step 2680, it is determined whether there are any 

support the multicast address proposed in the Broad- more members in the member list. If not, the function is 

castRequest message 2500. complete. If so, the next member from the membership list 

The BroadcastAck message 2500 allows a member to 5 is retrieved at step 2682. If the participant is already 

indicate whether n can receive messages over a proposed connected, is the member or is the member s own auxiliary 

multicast address. Another conference participant proposes source, as detected at step 2684 then the process returns to 

IZ - y 8 8 ^f^*^ messa f step 2680. It is detcrmmed, a. step 2686, whether this party 

iO^JiLn ZZX^V^^' 1 T % * § oin S 10 iniuate tbe i** wilh this member in the member 

broadcaslResponse field 2508 to '0 . Otherwise, the broad- in . ° ^r- m „ A „ to ' a - • • r , - 

castResponse field 2580 contains an appropriate non-zero J ° ^ *TT* conflicting join messages from being 

result code This message is Wpically used as part of the ™ Up ° D m DClW ° rk JhlS 15 acCOm " 

negotiation process that follows merging two conferences p if bed by dc,cmnniD g wtohcr recipient s conference 

As an optimization, conference participants may choose to ,D 13 ? caler ^ tne caU,n S P arl y' s conference ID. In this 

set up broadcast capabilities as a more-efficient alternative to case > lhis P 3 *? ^ lake action on the j° ,n ( c * P Iacc & c cal1 

maintaining several different point-to-point connections. 15 10 me olner party to accomplish the join). Operations nec- 

Join operations have the protocol illustrated in FIG. 9. essary to accomplish tbe join then lake place starting at step 

FIGS. 2&7-26r illustrate the process steps performed in a 2688. At this step, transport level connections are estab- 

transraitter and receiver during join operations. FIG. 26a lished. Once established, capabilities, if any, (or an auxiliary 

shows a process 2600 which includes the process steps message, in the case of an auxiliary source), hello, and join 

performed by a transmitter of a join message or any message 20 messages are sent at step 26 90. The member then waits for 

containing a member list. This may occur, for example, a response to the join, and if received in the affirmative, the 

responsive to an auxiliary or merge message. First, the conference component issues MemberReadv to the applica- 

transmitter creates a join message at step 2602. The desti- tion. This process continues until all members in the member 

nation conference ID and calling conference ID's are added list have been processed, 

to the message at step 2603. Then, at step 2604, a member 25 

is appended to the members list in the join message. This is Merge Operations 

^=l : shown in more detail in FIG. 266. A transport level connec- Merge operations are initiated using a "Merge" message 

jjjjf tion with the member to receive the join is then performed ( e g» 1900 of FIG. 19) which indicates to a participant that 

\=J at step 2605. Subsequent thereto, the message is then sent to rwo existing conferences should be merged. This is accord - 

f=j any recipients at step 2606. 50 irig to the conference ID contained within the field 1908 of 

^ FIG. 266 illustrates the "append members" function 2604 Message 1900. Each Merge message contains within it a 

M shown in FIG. 26a for appending members to a member list. memberList 1912 which allows the participating members to 

U I The function starts at step 2610 which determines whether transmit Join messages to all the members which have been 

M the member is a "joiner."' If so, then additional members can listed in the memberList. This further allows changing 

I ==; be appended to tbe join. If not, then the function ends and the 35 membership and conference ID during the course of a merge 

v 1 join message with the single member is transmitted as operation to be tracked so that correct conference ID's and 

s shown on FIG. 26a At 2612, the next member is retrieved conference membership may be maintained until after the 

y. according to the conference ID. At step 2614 it is determined merge. A merge operation is graphically illustrated with 

?s 1 whether there are any more members in the specified con- reference to FIGS. 26a and 266. For example, at a first time 

! ~ feicnce ID. If not, the process is complete. If there are more 40 period as illustrated in FIG. 26a, conference member ID 

H= members and the shareable mode flag is set, as detected at rnay be engaging in two conferences denoted 1 and 2 with 

fn step 2616, then the member is added to the member list at several other members, A, B, and C The member then 

s=£ step 2618. In this manner, during a merge operation, other proceeds to issue Merge messages to the members of con- 

; ; participants receiving join messages can determine if con- ferences. That is, member D issues join messages to mem- 

?== ference membership has changed, requiring additional join 45 bers A, B and C to Merge the conference 2 (denoted B, and 

messages to be transmitted by receiving members. C,). At the end of the operation, members A, B, C, and D all 

FIG. 26c shows the steps performed by a receiver of a join have point-to-point communication channels and the new 

message. First, at step 2652, the destination conference ID conference ID is the same, (A a , B„ C 2 , D Jf respectively in 

contained in the join message is looked up by the receiver in eacn of the members). The mechanics of this operation are 

a locally-stored current conferences history table (e.g. 2900 so described briefly with reference to FIGS. 28a-286. That is, 

of FIG. 29). This keeps track of previously used conference tne rwo separate conference* are now denoted by the same 

ID's for any currently active conferences. If the conference conference ID's in each of tbe members. 

ID has changed, the member can then complete the join by FIGS. 28a-286 show the steps taken during a merge 

referencing an old conference ID and the current conference operation by the conference component in the transmitter 

ID in the member. This allows for conference merge and 55 and receivers (if any) of a merge message. FIG. 28fl shows 

auxiliary messages from widely distributed members in a the process steps taken by a transmitter of a merge request, 

network. If the conference ID can't be found, as detected at I"he member first combines the conference ID's of the old 

step 2654, then the connection is refused at step 2656, by the and new conference in it's internal store at step 2802. Then, 

issuance of an appropriate response message, and the join at step 2804, the member creates the merge message and 

fails. If the conference ID has been found, then, at step 2660, 60 appends each of the members of the conference to the 

the connection is added to the list of participants for the members list in the message via the append members routine 

conference. At step 2662, a Response message that tbe join 2604 (discussed above) in order to ensure full connectivity 

can be performed is sent to the sender of the join. Then, the among all conference members. Then, at step 2806, the 

membership of the members contained in the member list of merge message is sent to all participants in the merge, 

the join can then be performed as shown in FIG. 26d. &> FIG. 286 shows process steps taken in a receiver receiving 

The merge membership function 2664 is shown in more a merge message. Once a merge message has been detected 

detail in FIG. 26rf. First, it is determined at step 2678 (step 2812), the merge recipient recalls in a local store for 
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example, the conference name and the conference ID ai step deactivated, and point-to-point communication continues to 

2814. Then, as discussed with reference to FIG. 26rf, above, be used for communication with the other members (this 

a merger of membership is performed (e.g. process 2664X optimization cannot be performed). The process is thus 

and the process is thus complete at step 2816. complete. 

In addition to using conference ID's for performing merge 5 Auxiliary Ooerations 

and subsequent join operations, contained within each . . 7 ^ 

Merge and Join message is a list of members of the confer- A° auxiliary media source can become part of an ongoing 

ences being merged or joined. These are included in the conference. The media source is associated with an ongoing 

meraberList fields 1812 or 1912 of messages 1800 or 1900. conference by a invoking reference to the main conference 

For example, due to propagation delays in a networking io stored in each conference component (e.g. by the API call 

system, old conference ID's may still exist in peripheral MTConferenceAttachAuxiliarySource), however, it is 

participants, and therefore during merging and or joining treated as a separate conference in each conference compo- 

operations, conference ID's may become invalid "due to neDt * For *™mpK as illustrated with reference to HG. 31, 

members merging conferences, etc. . . . , or reference a firsl conference referred to by conference ID 23B in 

conference ID's which no longer exist. Thus, contained 15 member B, may be notified of an auxiliary source having 

within each conference component in a member is a cu rrent conference ID 17A from member A. Note that similar to the 

conferences table such as 2900 shown in FIG. 29. The protocol illustrated with reference to the Capabilities and 

current conferences history table allows a member perform- HeUo rnessages in FIGS. 8 and 9 above, the Auxiliary 

ing a merge or join operation to determine whether in fact message may be sent in place of a Capabilities message 

conferences to be merged use old conference ID's. If so, 20 between a first endpoint and a second endpoint as illustrated 

then the new conference ID may be used to transmit to the* m FIG - 32 * ^ liming of the messages is illustrated with 

participants receiving the join messages, and/or be matched reference to FIG. 32. Similar to the capability and call 

to the appropriate conference ID. Thus, the member per- protocol illustrated with reference to FIG. 8 above, the 

forming the merge operation can reference by way of the Auxiliary message 3202 is received from the first endpoint 

current conference ID 2901 contained within the merged 25 32 1°» l ° notify endpoint 2 3220 that an auxiliary source is 

jy, conferences table, or other conference ID values 2902, available from the parent conference ID, as specified in 

~ containing a variable length list of conference ID's, to which parentConfID field 1704 of Auxiliary message 1700 of FIG. 

the current conference ID refers. Conference entries are 17. Then, a HeUo message 32W is transmitted from endpoint 

%J deleted at the end of a conference by the conference com- 1 3210 t0 point 2 3220. Responsive thereto, endpoint 2 

fy ponent. If a merge occurs at a peripheral location and a 30 3220 transmits capabilities message 3222 and Hello mes- 

^ conference ID becomes invalid, then the list of conference sa S c 3224 ' Subsequent thereto, a Join message 3226 with the 

ID's for an existing conference ID can be referenced by conference ID-23B is issued from the endpoint to 3220 with 

U1 referencing the merged conferences history table. me conference ID of the source in order to indicate that the 

Ljl . endpoint 3220 wishes to receive the auxiliary source AA, 

| p Multicast 35 shown in FIG. 31. Subsequent thereto, all messages from 

y 1 FIGS. 30a and 30b illustrate a process which is performed source A to recipient B as illustrated in FIG. 31 reference the 

2 as an optimization if multiple participants within a confer- same conference ID 23B for the ongoing conference 

ence support multicast address broadcast capabilities. First, between A and B. As illustrated in FIG. 31, the "receive 

^1 it is detected at step 3001 whether there are any more media" mode flag is set to not receive (IReceive) and 

7 transport media to be examined. If so, then the next is 40 furthermore, the mode of the auxiliary source is not joiner 

f=s retrieved at step 3002, and at step 3003 it is determined (!Joiner) since it is a receive-only media source. Subsequent 

fn whether two or more participants are in the same conference thereto, the second endpoint 3220 sends a response message 

and are on the same transport medium. If so, and the 3216 indicating that the auxiliary source has been success- 

transport medium supports multicast at step 3004, then the fully joined with the conference 23B. Subsequent thereto, 

|=* multicast capabilities of the transport medium are activated 45 both media messages for the conference ID 23B, and the 

at step 3006. If so, and the multicast capabilities are working auxiliary source having conference ID 17A are treated as 

at step 3008, then step 3008 proceeds to step 3012. If it is not from the same source (A) by the application. The details and 

working, as detected at step 3008, then the process is aborted mechanics of a member receiving an auxiliary source mes- 

at step 3010. At step 3012 a multicast address which may be sage arc illustrated with reference to FIGS. 33 and 34. 

used for the transport medium is retrieved at step 3012. 50 FIG. 33 shows the process steps performed within a 

Then, at 3014, Broadcast Requests are sent in substantially source of an auxiliary source. At step 3302, the next par- 

the formal as shown in Message 2400 of FIG. 24, io all the ticipant in the conference to which the auxiliary source will 

participants detected at step 3002 supporting multicast. The be attached is retrieved. It is determined, at step 3304, 

process then awaits BroadcastAck (in the format 2500 whether there are any more participants in the conference to 

shown in FIG. 25) in order to determine whether the 55 which the auxiliary source will be attached. If any, then, at 

multicast address is available for each at step 3016. If so, step 3306, auxiliary, hello and join messages are sent to the 

then for each BroadcastAck determined to be received at participant. If accepted via a positive response message (as 

step 3018, and it is determined whether the BroadcastAck shown in FIG. 32), the auxiliary then becomes available to 

was positive (due to the response value contained in field the participant for the receiver of the message. The process 

2508 of FIG. 25). At step 3022, if the response was positive, 60 continues until step 3304 determines that no additional 

then the point-to-point connection is deactivated. Once all participants in the conference sbou Id join in to monitoring of 

the Broadcast Acks have been received (or have timed-out), the auxiliary. 

then it is determined at step 3024 whether there was a FIG. 34 shows the steps taken by a receiver upon receipt 

Broadcast Ack received for each Broadcast Request message of the initial auxiliary message. At step 3402, capabilities (if 

sent. If not, then the process is complete. If so, however, step 65 any), and hello are sent. At step 3404, the auxiliary source 

3026 determines whether there were any positive Broad- media starts to be received, and the conf ID of the parent 

castAck for the multicast. If not, then multicast is conference is saved in the conference component of the 



